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This memo provides information for the Internet community. It does 
not specify an Internet standard of any kind. Distribution of this 
memo is unlimited. 


Abstract 


This document describes experiences of operational requirements and 
several considerations for ENUM-based softswitches concerning call 
routing between two Korean Voice over IP (VoIP) carriers, gained 
during the ENUM pre-commercial trial hosted by the National Internet 
Development Agency of Korea (NIDA) in 2006. 


These experiences show that an interim solution can maintain the 
stability of ongoing commercial softswitch system operations during 
the initial stage of ENUM service, where the DNS does not have 
sufficient data for the majority of calls. 
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1. Introduction 


ENUM [RFC3761] is a mapping system based on DNS [RFC1034] [RFC1035] 
that converts from an E.164 [E164] number to a domain name using the 
Naming Authority Pointer (NAPTR) [RFC3403] resource record type. 
ENUM is able to store different service types (such as fax, email, 
homepage, SIP, H.323 and so on) for every E.164 number. It 
originally focused on how end-users could gain access to other end- 
users’ communication contact information through the Internet. 


Recently, discussion on the need to update RFC 3761 has begun to 
ensure that the standard also works in the "Infrastructure ENUM" 
scenario, where ENUM provides routing information between carriers. 
This resulted in two documents, the updated ENUM specification 
[RFC3761lbis] and an Enumservice guide [ENUMSERVICE-GUIDE]. 


When providing VoIP service, a VoIP carrier that wants to integrate 
various protocols typically uses a softswitch. However, such a 
system is still inefficient for interconnection, number portability, 
and sharing protocol support information among carriers, because each 
softswitch does not have complete end-to-end routing information for 
all carriers. This information can be stored in DNS, using ENUM. 
Therefore, carriers can expect to gain many advantages if they use 
ENUM within the call routing functions of their softswitches. 


To confirm these benefits and to verify the performance of ENUM- 
enabled softswitches, NIDA cooperated with two Korean VoIP service 
providers for an Infrastructure ENUM trial in 2006. NIDA is a non- 
profit organization with a mandate to manage 2.8.e164.arpa. 
(representing the +82 country code of Korea). NIDA promotes and 
facilitates technical cooperation on a national scale between 
partners, and this includes ENUM. During the trial, NIDA provided a 
centralized ENUM DNS to each VoIP service provider for call routing. 
The data used in this Infrastructure trial was also accessible to the 
public (i.e., it was an Internet-based system, rather than a closed 
scheme). 


2. Call Routing on Softswitch 


In the PSTN (Public Switched Telephone Network), hardware-based 
switches predominate. A softswitch provides similar functionality, 
but is implemented on a computer system by software. It typically 
has to support various signalling protocols (such as SIP [RFC3261], 
H.323 [H323], Media Gateway Control Protocol (MGCP) [RFC3435], and 
others) to make call connections for VoIP service, often on the 
boundary point between the circuit and packet network. 
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To make a call, first of all a softswitch must discover routing 
information. It has to process the E.164 number that comes from a 
caller through its own routing table. The goal is to determine how 
the call can be routed towards the callee, so that either the call 
can be processed through the softswitch or the caller can connect to 
the callee directly. 


Today, call routing is often based on a prefix of the dialled number. 
This is used very widely not only for legacy PSTN switches, but also 
for softswitches. So, if a softswitch exclusively uses ENUM DNS for 
call routing, then, in the beginning most of the calls queried to 
ENUM DNS would fail if there are only a small group of carriers 
provisioning data into ENUM. However, a softswitch will have a 
higher success rate with ENUM DNS as the number of carriers grows, 
and so the overall percentage of numbers provisioned in ENUM 
increases. In short, ENUM as a long-term solution has obvious 
benefits, but the problem lies in migrating from today’s prefix—based 
routing towards that long-term ENUM-based solution. 


3. Infrastructure ENUM Trial in Korea 


As described in Section 1, NIDA and two VoIP service providers built 
ENUM-processing modules into their softswitches, interconnected these 
via the IP network, and provisioned their trial users’ numbers into a 
centralized ENUM DNS system operated by NIDA. The carriers 
provisioned their E.164 numbers using Extensible Provisioning 


Protocol (EPP) [RFC4114] to a centralized Registration Server (also 
operated by NIDA). Changes to the ENUM data were implemented and 
updated to the ENUM DNS instantly, using DNS Dynamic Update 
[RFC2136]. 


In the trial, the EPP-based provisioning sub-system was developed and 
operated separately from the carriers’ main customer provisioning 
systems and protocols. It was not integrated, as the carriers 
already operated their own customer provisioning systems that were 
totally different from the EPP-based model, and (as mission-critical 
components) those were not open to modification. 
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Call routing 


4--------------------------------------------- + 
4+----- 4+------ + 4----------------- + 4+------ 4+----- + 
Softswitch A|------ | ENUM DNS(+82)  |------ Softswitch B 
+----- +------ + | (Tier1,2) | +-----—- +----- + 
4+-------- 4+-------- + 
4+----- 4+------ + 4+------ 4+----- + 
IP Phone A Dynamic Update | IP Phone B 
+------------ + | (RFC 2136) +------------ + 
+------------ + 4+-------- | -------- + 4+------------ + 
| EPP Client | | Registration | | EPP Client | 
| |------ | Server [eet | | 
4+------------ + 4+----------------- + 4------------ + 


Provisioning E.164 Numbers (RFC 4114) 
Carrier A NIDA Carrier B 
Figure 1: Infrastructure ENUM Trial System Topology 
4. Operational Requirements for ENUM-Based Softswitches 
4.1. Call Routing Cases for DNS Response Codes 


To use ENUM DNS, each softswitch needs to have an ENUM module that 
converts from an E.164 number to the ENUM domain name (as defined in 
RFC 3761) and processes a query to ENUM DNS. This ENUM module uses 
the algorithm specified in RFC 3761. 


However, in the initial stage of ENUM DNS roll-out, ENUM shares call 
routing information from a limited number of carriers. There is the 
problem that a softswitch can’t find all of the call routing 
information it needs just using ENUM. To solve this problem, ENUM- 
based softswitches have to follow a consistent set of rules. 


4.1.1. Trial Policies 


As a matter of policy in this trial, all telephone numbers in use 
within an "ENUM only" number range (i.e., ones in which an endpoint 
could only be reached via a URI found during an ENUM lookup of a 
telephone number in this range, and for which there was no PSTN Point 
of Interconnect) were arranged to return a NAPTR response. For 
ranges in which there was a PSTN Point of Interconnect, this was not 
required. 
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Thus, no data (at all) needed to be provisioned into an associated 
ENUM domain for such a number if it were possible to "reach" that 
number via the PSTN, unless there were also an IP-based Point of 
Interconnect serving that number and the serving carrier chose to 
make this option available. 


In those domains in which NAPTRs for ENUM processing were 
provisioned, these NAPTRs were always ’terminal’ rules -- non- 
terminal NAPTRs were not used. If non-terminal NAPTRs were to be 
provisioned, then the standard operation of ENUM processing might 
have required extra DNS lookups before the set of NAPTRs for a 
telephone number could be evaluated. The delay and indeterminacy 
this would introduce was not considered acceptable. 


The case where a valid URI was present is covered in Section 4.1.2 
(rule 2 A, second point). The case where an ENUM entry was not 
provisioned for a number that had an active PSTN Point of 
Interconnect is covered in Section 4.1.2 (rule 2 B). 


For "ENUM only" ranges, where a given number in that range was in 
service (i.e., there was an IP-based Point of Interconnect to a 
carrier), a valid SIP or H.323 URI was always provisioned into the 
associated ENUM domain. This is covered in Section 4.1.2 (rule 2 A, 
second point). 


In such an "ENUM only" range, if the number was not in service, a TXT 
record was provisioned but no valid NAPTRs would be present. This 
ensured that a query for NAPTRs in a given (out of service, "ENUM 
only" range) domain would succeed (i.e., return a RCODE of 0), but 
that the number of answers would also be zero. This is covered in 
Section 4.1.2 (rule 2 A, first point). Note that this point also 
covers the case where only NAPTRs that cannot be used to initiate a 
call exist in such a zone. 


Where a valid URI was provisioned, the ENUM lookup would complete by 
returning that value for further processing. This further processing 
is covered in Section 4.2. 


For "ENUM only" ranges, there was a further policy requirement that 
an IP-based Point of Interconnect specified inside a NAPTR (as the 
domainpart of a valid URI) must be accessible for all potential 
carriers. The server could reject a subsequent SIP Invitation, but 
its machine address had to resolve. This was intended to avoid the 
condition where the domain name did not resolve, the softswitch logic 
would attempt to place the call via the PSTN, and this would fail 
and/or loop. 
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This "must resolve" requirement was not needed for numbers that had 
an active PSTN Point of Interconnect (i.e., the vast majority of 
assigned numbers). If the domain name did not resolve, the call 
would "drop back" to PSTN processing. 


4.1.2. Trial ENUM Lookup Rules 


In the Korean trial, the rules were: 


1. The ENUM module of the softswitch converts an E.164 number coming 
from the VoIP subscriber to an ENUM domain name (as defined in 
RFC 3761). 

2. The ENUM module, acting as a DNS stub resolver, sends a query to 


a recursive name server. 


3. If the ENUM module receives a DNS answer, the call routing 
process may branch off in several ways, depending on the Rcode 
value in the DNS response message, as shown below. 


A. Rcode=0 (No error condition) 
There is, potentially, an answer to the corresponding query. 
The normal call routing process needs to differentiate 
between the following conditions: 


+ The response includes no URI (such as SIP or H.323) that 
can be used to initiate a call -- 
The call fails immediately. 
Note: In the trial, the condition in which a telephone 
number: 


- is valid, 
- can only be reached via the Internet, but 
- is not currently in service 


is indicated by an ENUM domain that DOES exist but DOES 
NOT include any supported (routable) NAPTRs. A softswitch 
receiving this response interprets it as indicating that 
the call can be dropped immediately -- it would fail if 
passed to the PSTN. 


+ There is at least one usable URI (such as SIP and/or H.323 
URIs) -- 
The softswitch picks one based on the preference and order 
field values in the NAPTR Resource Record Set, and routes 
the call using the method described in Section 4.2. 
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B. Rcode=3 (Name error), 1 (Format Error), 2 (Server Failure), 4 
(Not Implemented), or 5 (Refused) 
There is no valid answer for the query. 
The softswitch has no choice but to route the call using the 
E.164 number with its vendor-specific method (such as a 
prefix-based method). In this case, it means that the call 
has to be delivered through the PSTN for onward call routing. 


It is also important to stress that the ENUM DNS servers must 
respond to all queries they receive from the softswitches. 

If the ENUM module in a softswitch does not receive a 
response, it will eventually time out, and the ENUM module 
will treat this as a DNS error. However, the delay involved 
is long in terms of the normal call setup time, and should be 
avoided. 

It would have been possible to modify the DNS code in each 
softswitch to have shorter time-outs than normal to cover 
misconfiguration of a DNS server, but this choice was not 
considered in the trial. The softswitch DNS stack was used 
for several purposes other than "pure" ENUM lookups. 
Configuring it in a non-complaint manner was considered 
unacceptable, due to the need to analyze the impact of that 
choice on other DNS operations thoroughly before it could be 
implemented safely. 


Call Routing Cases for Domainparts 


If the DNS response has a valid URI, such as SIP or H.323, the 


softswitch can resolve the domain name part of that URI to route a 
call by searching two different sources. One is a recursive 
nameserver, and the other is a fixed routing table held in the 
softswitch, mapping from the domain name to the corresponding 
gateway’s host name and IP address. 


If there are many points of interconnection, using a recursive 


nameserver is useful for resolving a domain name, but if there are 


just a few known carriers and they do not change this interconnection 


information frequently, a fixed (internal) routing table mapping from 
domain name to the corresponding gateway hostname and IP address is 
more efficient (rather than querying the recursive nameserver every 
time). In addition, carriers would like to charge an interconnection 
fee for all received calls, so they tend to make interconnection only 
with trusted carriers based on some sort of bilateral agreement 
between these carriers. They may agree on a specific gateway for 
this purpose, so the interconnection information is often private to 
the parties of this particular agreement. 
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In principle, these two approaches could be used in parallel, but in 
practice, if the DNS-based approach could be used, there would be no 
point in retaining the expensive and elaborate "offline" 
infrastructure to exchange and install the tables for domain routing. 
In this trial, uncertainty over the performance and reliability of 
ENUM-based processing meant that the softswtitches were configured so 
that they could be switched between the two approaches immediately. 
This was a temporary expedient only, and would not be a reasonable 
approach in the long term. 


These two types of domain routing are also affected by the Rcode=0 
case described in Section 4.1. 


There are two choices for routing. These are described and compared 
here: 


1. Case when using a fixed routing table: 


A. If the domain name part of the URI is found in the internal 
fixed routing table, the softswitch can use it. 


B. If the domain name part of the URI does not exist in the 
fixed routing table, the call is forwarded to the PSTN. 


2. Case when using a recursive nameserver: 


A. If the domain name part of the URI can be resolved via the 
recursive nameserver, the softswitch can use it. 


B. If the domain name part of the URI cannot be resolved on the 
recursive nameserver for any reason (such as a response with 
no usable resource records according to [RFC3263] and 
[RFC3261], or with Rcode=1, 2, 3, 4, or 5), the call must be 
forwarded to the PSTN. 


Case (1) seems inefficient because the administrator maintains two 
management points for numbers: the ENUM DNS and the softswitch 
itself. However, this configuration can minimize the call routing 
failure ratio during the transition period of ENUM (when there are 
relatively few provisioned ENUM entries and so few IP-based Points Of 
Interconnection). Thus, case (1) could reasonably be implemented on 
the softswitches during the trial phase, and thereafter, as ENUM 
entries are populated, case (2) would be a reasonable choice. 


With these choices, the two carriers could use ENUM DNS for call 
routing without any impact on their ongoing commercial VoIP service. 
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5. Trial Results 


To provide a stable commercial service, an ENUM-based softswitch must 
have a defined performance, in the same way as must any non-ENUM-— 
based softswitch. The only difference between these two types of 
softswitches is the searching mechanism for call routing information, 
which can be stored in the softswitch itself or in the DNS. 
Therefore, a similar delay time for call routing is important to 
guarantee quality of service. During the trial, each carrier 
measured this delay time when using the SIP protocol. This was based 
on the "Answer Delay time", defined as the elapsed time between 
requesting a call (’INVITE’ message) and receiving a response (’200 
OK’ message) [RFC3261]. 


4+------------------------ 4+------ 4+---------- + 
| Call Type | ENUM | Non-ENUM | 
4+------------------------ 4+------ 4+---------- + 
| Carrier A->A | 2.33 | 2.28. | 
| Carrier A->B | 223a 225 || 
| Carrier A->other (PSTN) | 4.11 | 3.79 | 
| Carrier B->B | 2.18 | 2.05 | 
Carrier B->A 2.19 2.19 
Carrier B->other (PSTN) 395 3.41 
4+------------------------ 4+------ 4+---------- + 


Table 1: Average Answer Delay Time (Sec) 


As shown in Table 1, there is little difference in time (under a 
second) between the ENUM and non-ENUM cases. Therefore, it is 
difficult for a caller with either carrier to detect the choice (ENUM 
or non-ENUM) as an aspect of quality when a call initiates. This 
means that ENUM definitely works well with softswitches ona 
commercial basis. 


To make the trial more realistic, the resolver that was used by these 
ENUM-based softswitches was a recursive nameserver that could be 
accessed publicly. This was done as it was felt that a tough 
condition would be better to verify the fact that an ENUM-based 
softswitch works as well as a non-ENUM-based softswitch in providing 
a commercial VoIP service. 


6. ‘’'e164.arpa’ Considerations 
During the trial, the Infrastructure ENUM deployed in the 
2.8.e164.arpa zone could be accessed via the (public) Internet. In 


this situation, each carrier questioned whether or not the 
centralized number management under the ENUM DNS was realistic. 
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Another issue concerned responsibility for routing errors. All 
carriers can use the shared ENUM data to route their calls. However, 
if there are routing errors (due to the data being provisioned 
incorrectly), it is not always clear who has responsibility for these 
errors and who can correct the data. The errors occur in the 
networks of the carriers placing the calls. Unless the identity of 
the carrier responsible for delivering service to this telephone 
number is known, it is not obvious (to the carrier handling the 
error) who should be informed of these problems. This is a 
particular issue when number portability is introduced. 


In addition, the carriers also question whether or not Infrastructure 
ENUM needs to be accessible publicly. To prevent disclosure of 
telephone numbers, they would prefer to access the ENUM DNS 
privately. Therefore, any ENUM module embedded in a softswitch needs 
to be flexible to adopt these considerations during the interim 
period of ENUM, before common policies and agreements have been 
forged. 


7. Security Considerations 


This document inherits the security considerations described in RFC 
3761 and [RFC5067], as the ENUM DNS used with softswitches in this 
trial could be accessed publicly. 


In addition, if the recursive resolvers handling ENUM queries coming 
from a softswitch were to be compromised by an attacker, that 
attacker would be able to force calls to fail or cause delay to 
calls. Therefore, the DNS resolvers used should allow access from 
the local network to which the softswitch is connected, whilst 
restricting access from outside, using a proper access-list policy. 
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